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The Society has, for a number of years, been actively studying the appli- 
cation of computer technology to our curatorial record system. Properly 
developed, the data base would have significant application in two im- 
portant areas: greater and more efficient use of our collections for re- 
search purposes and far better inventory control over our collections than 
now exists. 

For some time the sheer size of the projected data base constituted a 
formidable obstacle to progress. A large-scale computer seemed indicated. We 
were discouraged at the high on-going costs, the necessity to adapt our in- 
formation needs to existing programs and the cumbersome procedures for getting 
data into and out of the remote computer facility. 

However in the fall of 1973, Mr. Bass initiated discussions between 
the staff and a Dallas-based data processing consultant firm. The Corporation 
for Distributed Systems (CDS), with regard to the feasibility of a wholly- 
owned, in-house system to meet the Society's needs. These conferences led 
to a consultantship contract with CDS under which we defined our research 
and inventory control requirements and CDS developed a hardware/software 
configuration to meet these needs within a realistic budget. 

In July 1979, CDS issued their consultant's report in the form of a 
proposal recommending acquisition by the Society of an in-house computer 
facility. Bill Metcalf and I have reviewed the proposal in depth. We have 
discussed the content of the report in great detail with its author. Skip 
Hill of CDS. In addition we submitted the proposal to Hans Rutimann, Director 
of Data Processing Services at the Modern Language Association, and to Bill 
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Pollock who developed the program used by the Museum of the American Indian 
to place the record of its entire collection on computer. 

Both Rutimann and Pollock expressed admiration for Hill’s proposed solution 
to our collection management problem. Each has indicated that the hardware/ 
software configuration outlined in the report is feasible and imaginatively 
conceived. Both have also made suggestions which have been discussed with 
Hill and have aided me in developing the acquisition and operating budgets. 

In February Bill and I visited the Axxess Corp. in Mountainside, N.J., 
the company proposed as the OEM by Hill. Axxess has the desired hardware/ 
software configuration, based on the PRIME 400 CPU and 300 MB disk drive, 
with other peripherals by independent manufacturers, which Hill proposes for 
the ANS. Hill would, of course, modify "information management" programs to 
suit our particular needs. 

While at Axxess, we discussed a number of points relating to the perfor- 
mance of the proposed peripheral equipment and had demonstrated to us some of 
the key input and inquiry procedures so that we could better appreciate the 
processes described in Hill's proposal and evaluate the time and labor in- 
volved in these steps. Hill has proposed that input be accomplished by dis- 
playing on the CRT the categories of information required for each coin, 
requiring the operator to fill in the appropriate blanks. For subsequent coins 
in the same general sequence, the operator is required to change only those 
parts of the coin record which are discreet. The computer then stores a com- 
plete record for each coin. The method for accomplishing this time-saving 
input was demonstrated to our satisfaction. In addition we participated in a 
variety of on-line inquiries demonstrating the speed of the Prime 400 at 
sorting data as well as methods of data search. 

Finally, while at Axxess, we discussed Prime maintenance agreements and 
the company's service history. Subsequently I went over the basic Prime 
maintenance agreement for the proposed CPU and peripherals with Bob Hasel, 
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Prime's Manager, Field Engineering for the New York region and have been 
satisfied as to their service speed and reliability. 

In summary, we have confirmed independently that the proposal, as 
submitted by CDS and as modified on the basis of subsequent review, describes 
a feasible hardware/software configuration to accomplish the Society's 
stated primary objective of creating a unified data base of our numismatic 
collections with on-line inquiry capabilities. The proposed system also has 
application for the eventual computerization of the library catalogue follow- 
ing completion of the reorganization project, as well as membership, 
accounting and similar record keeping functions now maintained manually. 

Recommendation to Proceed 

Since the concept is feasible, the decision to proceed will be based on 
cost consideration. We are projecting a total capital acquisition cost of just 
under $160,000 with ongoing operating, maintenance and programming expenses 
approaching $50,000 per year. The Society does not now have any data pro- 
cessing expenses which would be offset by acquisition of an in-house facility. 
Revenues for services provided to the public are expected to be minimal. 

An in-house system would, however, provide an accurate, indexed and 
manipulable record of the Society's holdings which does not now exist, and 
which will facilitate recording of future acquisitions in a manner consistent 
with modern museum practice. It will give us the capability to recall immedi- 
ately all information known about any given acquisition and even enable the 
reconstruction of accessions whose components are scattered throughout the 
collection. 

The record will not provide a capability to identify duplicate or dis- 
posable material which does not now exist; but by serving as an auditing 
device it will significantly increase the security of the collection, and if 
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necessary permit the physical rearrangement of certain extraordinarily 
valuable concentrations of coins while retaining their accessibility. 

An equally significant benefit will be easier access to our holdings, 
which will improve both the speed and the quality of our service to the 
general public and the scholarly community. We can certainly anticipate 
greater utilization of our holdings as a result of this easier access, both 
on and off the premises. This in turn will encourage volunteers to assist 
in refining our records in specific areas of their expertise. The increased 
ability to define the strengths and weaknesses of the Society's collection - 
even to generate "want lists" if this is thought desirable - will provide 
the opportunity for a new kind of relationship with our donors which will 
ultimately work to the Society's benefit. 

At the scholarly level, the curatorial staff will be able to devise and 
perform projects which cannot now be performed manually, and perhaps ulti- 
mately to integrate the Society's records with those of other institutions 
elsewhere. The result would be a vast reduction in the time-consuming labor 
of assembling data, and greater scholarly productivity. 

Should the decision be taken to proceed with acquisition of the system, 
we would want to meet with the principals of CDS to discuss matters of pro- 
cedure, responsibility and schedule. From this meeting we would prepare a 
written agreement which would provide the basis for the acquisition, testing 
and installation of the system. It is reasonable to estimate that the system 
could be operational within one year. 
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FINANCIAL DATA 


ANS PRIME SYSTEM 


Capital Costs 


Acquisition : 

PRIME system, per proposal as modified to 

include Model 400 CPU and 300 MB Disk Drive 
and total of 3 ADDS Regency 25 CRT units 
300 MB disk pack plus backup 
Voltage Regulator 
Shipping 

Total Acquisition 
Site Preparation: 

Construction, electric and air handling 
Cable runs for CRT units 

Total Site Preparation 

Contingency: 

Hardware (10%) 

Application Software Development (50%) 

Total Contingency 
Total Capital Costs 


124 

,800 

2 

,200 

1 

,800 


500 

129 

,300 

8 

,800 


700 

9 

,500 

12 

,900 

7 

,000 

19 

,900 

158 

CD 

1 ° 
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Estimated Operating Costs 


Personnel : 

Operator 1 - Salary, Taxes, 
Benefits (note 1) 

Operator 2 - Salary, Taxes, 
Benefits 

Programming - Revisions 
and Additions (Note 2) 

Operations : 

Electric - 9 KVA 
Supplies (Note 3) 

PRIME Maintenance 
Agreem.ent (Note 4) 

Annual Operating Costs 


Year 1 


2 


3 


4 


5 

$ 12,575 

$ 

13,575 

$ 

14,665 

$ 

17,075 

$ 

18,475 

12,575 


13,575 


14,665 





1,000 


2,400 


2,400 


8,000 


8,000 

2,520 


2,720 


2,940 


3,175 


3,430 

2,160 


2,330 


2,520 


2,720 


2,950 

9,0OO 


12,000 


12,960 


14,000 


15,120 

$ 39,830 

$ 

46,600 

$ 

50,150 

$ 

44,970 

$ 

47,975 


Av. /month 


3,319 3.3883 4,179 


Annual Operating Costs, 1 operator 27,255 

Av. /month 2,271 


33,025 

2,752 


35,485 

2,957 


3,748 3,998 


Notes 


1. Based on starting salary of $195/wk and 8% annual increments. Operator 2 is hired only 
for the initial imputting stage; Operator 1 is proposed as an additional staff position. 

2. Based on rates quoted in proposal for CDS personnal. Amounts for years 4 and 5 
anticipate added software* for library and accounting functions. 

3. Supplies include paper, print ribbons, magnetic tape, incidentals. 

4. Maintenance contract begins after initial 90 day warranty period. 
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1.0 INTRODUCTION 


1.1 PURPOSE OF PROPOSAL 

This proposal results from the completion of the general systems analysis and 
preliminary hardware evaluation phase of a search for a computer based coin 
cataloguing and research facility, conducted by the Corporation for Distributed 
Systems (CDS) . 

1.2 GENERAL CONSIDERATIONS AND RECOMMENDATIONS 

The actual data processing functions required by the ANS application are 
fundamentally Identical to most other business applications, but the amount 
of data storage required, the data variability, and the many ways the data 
must be accessible make the ANS project unique from both hardware and 
software perspective, 

Fevj micro processor systems offer disk storage peripherals that meet your 
requirements, and many mini computer systems that do meet the requirements 
are too expensive, have not established a reliable reputation, or do not 
offer software suitable to your application. l-Jhile a micro processor system 
could be designed to meet your application requirements, there would be many 
disadvantages to such a solution. Presently, there are no single source 
micro processor systems available with the required hardware that meet our 
reliability requirements. Therefore, we would have to configure a system 
using equipment from several vendors and design and build hardware and software 
to integrate the equipment into a final system to support your application. 
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The complexities of such a project are difficult enough, but, more importantly, 
the disadvantage of such an approach would be the inflexibility of the final 
system. It would serve only the very specific and limited application to be 
defined explicity in Phase II of our methodology. Additional applications could 
not be added, nor could the existing data base be altered without a great deal 
of work on our part. Data content, keys, and indices in the existing data base 
would remain the same for the life of the system. 

On the other hand, hardware and much of the software needed for your application 
is available, tried and field proven, from several mini computer vendors. We 
feel that the higher cost of the hardware for such a system is far outweighed 
by lower software development costs and a much more flexible final product. Such 
a system would be suitable for addition of new applications in the future, and 
the existing data base could be changed without incurring impractical expense. 

New data fields, keys, indices, and reports could be added to the system with ease. 

We therefore recommend that a mini computer based system approach to your appli- 
cation would prove to be a much more viable investment for now and the future. 
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2,0 SYSTEM OVERVIEW 


2.1 INTRODUCTION 

CDS has prepared the following system overview in order to qualify the proposed 
system. It may be helpful at this time to point out the appendix A at the end 
of the proposal, listing a number of terms and words used in this proposal. The 
application baseline design consists of the functional diagrams, files lists, 
and module descriptions, and will apply generally to either a micro processor 
or mini computer system, regardless of vendor. CDS will warrant the software 
developed for 310 days from date of acceptance, and during the warranty period, 
CDS will correct free of charge any errors found. CDS will guarantee that the 
software will meet design requirements,, and will perform according to design 
specifications . 

After the warranty period CDS will maintain all software developed, and will 
be available at normal rates for modifications to existing software, or develop- 
ment of software for new applications. ANS will receive from CDS complete source 
code and documentation for applications program to facilitate future software 
development by others at discretion of ANS. 

2.2 APPLICATION BASELINE DESIGN 

The diagrams on the following pages depict the fundamental or baseline design of 
your application requirements by a technique known as functional decomposition. 
By " functional decomposition" we mean the isolation of separate processes into 
groupings by related functional intent. We feel that this type of presentation 
answers best the "What" of systems analysis and leaves the definition of pro- 
cedural flow within these functional constraints until Phase II, Detailed 
System Design. Following the diagram is a short description of each functional 
component . 
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2.2.1 FILES 


All of the components or modules depicted on the preceding pages manipulate 
data from the following two major files: 

* ACCESSION HISTORY FILE 

This file will contain all information now entered in the 
accession journals, minus detailed information for individual 
coins, which will be contained in the coin catalog file. The 
details of actual data to be stored will include: accession 
number, date, general description of coins in accession, previous 
collections, from whom, cost, type of accession, and number 
of objects. (See section 3 for details on contents of this file). 

* COIN CATALOG FILE 

The coin catalog file will contain all detailed information for 
the entire ANS collection of coins. (See section 3 for details 
on contents of this file). 
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2.2.3 MODULE DESCRIPTIONS 


* SYSTEM MAINTENANCE 

This functional sub-system will provide for all system and data file 
maintenance. Programs will allow addition and deletion of keyed/non- 
keyed data fields to be stored with each accession record or coin 
description, optimization of disk storage usage, backup of data to 
tape and reloading of data from tape in event of disk failure. 


* DATA ENTRY 

This sub-system will provide for data entry and validation for all 
information destined for one of the two major files, accession history, 
and coin catalogue. (See section 4 for details on actual format of 
CRT screen for collection of data) . 

* STANDARD REPORTS 

This sub-system will provide for generation of all standard reports 
including master accession and coin listings for each department. 

* INQUIRY 

This sub-system will provide the administrative inquiry and research 
facility into the data base of coin descriptions and accession 
history. It will allow a trained operator to perform "searches" of 
the coin catalogue based on entered selection criteria. 
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2.2.4 


MENU TECHNIQUE 


The proposed system is envisioned for the most part as a menu driven appli- 
cation which will make operation extremely easy to learn. The main menu 
would appear something as follows: 


A N S 

MAIN MENU SYSTEM SELECTOR 

1 SYSTEM MAINTENANCE UTILITIES 

2 DATA ENTRY 

3 STANDARD REPORT GENERATION 

4 DATA BASE INQUIRIES 


The operator would select the desired sub-system by typing the appropriate 
number, and another menu would appear, providing for more specific selection 
within the sub-system chosen. 

The specific data entry programs within selection 2 would function a little 
differently, but are designed to be ^asy to learn and operate also (see section 
4 for details). The inquiry sub-system would be different from menu selection, 
allowing for entry of English like sentences specifying search criteria and 
report output format (see section 7 for details). 
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2.3 GENERAL HARDWARE CONFIGURATION 


Aq a result of our general systems analysis, the proposed system will contain 
the hardware components described below. These components will be the same for 
either a micro processor or mini computer based system. 

* CPU AND MEMORY - PRIME 400 

Our analysis indicates that the CPU will have to be powerful enough 
to provide for reasonable performance in the INQUIRY sub-system, and 
we estimate a need for at least 256 KB (kilo-bytes) of memory for 
efficient operation of your application. A major part of the available 
memory will be used to hold the file indices. (These file indices must 
be held in memory for efficient data base searches, and will be very 
large due to the large number of records in the data base) . 


* DISK STORAGE UNIT - PRIME 300 MB 

Our analysis indicates a need for approximately 250 MB (million bytes) 
of disk storage based on the estimated number of accessions and coins 
in your catalogs. The Prime 300MB disk storage unit is almost the same 
price as the 80MB. 


* MAGNETIC TAPE UNIT 

Our analysis indicates that for your application, it is imperative to 
provide adequate backup for the major data files, so that no data will 
be lost in the event of a disk malfunction. The tape unit will be used 
primarily for backup and may possibly be used for storage of some of 
the "free text" associated with coin descriptions. 

* PRINTER 

The printer will be used for output of standard reports and inquiry 


14 


results. Our analysis shows that the printer would have a relatively 
light work load with the exception of yearly master lists, therefore 
we recommend a 200 CPS (characters per second) printer. A slower 
printer would make production of large reports require literally days 
of print time, and performance of such a printer would quickly degrade 
Faster additional printers can easily be added to a mini computer 
system later if the need becomes apparent. Reports can be produced on 
tape for conversion to hard copy by service bureau high-speed printers 


* CRT - ADDS REGENCY 25 

The CRT's will be used for data entry and research. Three units are 
included in the initial configuration. The performance characteristics 
of a given hardware configuration are complicated to assess at best, 
but will alw’ays degrade with addition of more terminals. The PRIME 400 
is designed to accommodate up to sixty-four (64) CRT's. 


15 


3.0 DATA BASE REQUIREMENTS 


3.1 INTRODUCTION 

This section addresses the information storage requirements for your application. 
This refers to the fields or data to be stored in each of the two major files, 
and includes a preliminary list of fields that should be keys. The analysis of 

disk storage requirements is based on the following four (4) types of data 

required by your application; 

I. TABLE LOOKUP 

This storage technique is used for data fields that have a limited 
number of unique values, such as coin material. Instead of storing 
the field 'silver' in each record where appropriate, a code value of 
'!' would be stored which, when looked up in a table would expand to 
the actual meaning of the code. Application of this technique where 
applicable can save literally millions of bytes of storage. A practical 
limit for the number a unique values a field of this type may have 
is sixty four (64). 

II. FIXED SIZE FIELD 

This type is used for fields that will have too many unique values for 

type I, but which can practically be limited to a fixed number of 

characters (bytes). As an example, consider the field 'mint'. There 
are far too many different (unique) mint names to use type I, however 
most all mint names could be stored in a twenty (20) character fixed 
size field, and those that are longer could be suitably abbreviated. 
Numeric variables that are too large for type IV are stored as this 
type of data, and also decimal numbers such as 'price'. 
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III. VARIABLE LENGTH TEXT 


This data type will be used for information which may vary in length 
from one (1) to sixty four (64) lines of textual information. An example 
of this data type would be 'how acquired’ in the accession history file. 
This textual information would be stored unchanged in the system, but 
the actual means of access to it would be through a list of keywords 
specified separately, but contained within the text. For example, a coin 
with a subject of Pliny the Elder might have thirty or forty lines of text 
describing the content of the coins surfaces, and list of keywords in- 
cluding Pliny; Elder; Roman; poet; writer, etc. Any time a search inquiry 
specified 'poet' as one of the selection criteria, this coin’s record would 
be selected and all information about it, including all of the text, would 
be available for displaying to the terminal or printer. 


IV. NUMERIC 

This data type will be used for fields that are strictly integer numbers 
(whole numbers like 1234 and not decimal like 1.234). An example of this 
data type would be ’dates’. The following tables summarize the data fields 
to be stored in the two major files, their type and size where applicable. 

An estimate of the storage requirements for the application can be made 
from these tables as follows. For the accession history file, assuming a 
limit of about ten lines of free text associated with each accession re- 
cord, the application would require about 1000 characters per accession 
record. Our analysis indicates that since 1938, you have acquired about 
250 accessions per year which gives approximately 10,000 existing accession 
records. This works out to about 10 MB of storage for the accession file. 
For the coin catalog, a little bit more complex approach is required. Our 
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study indicates that perhaps 10% of the coins will require complete and 
detailed descriptive information, another 10-15% will have some detailed 
information, and the rest will have type I, II, and IV fields entered, 
but little free text. Based on these estimates, the storage requirements 
for the coin catalog file break down to the following; 


10% 

of 

1,000,000 

coins 

X 

1000 

characters 

ea. 

= 100 

MB 

10% 

of 

1,000,000 

coins 

X 

400 

characters 

ea. 

= 40 

MB 

80% 

of 

1,000,000 

coins 

X 

100 

characters 

ea. 

= 80 

MB 


Note that these are generous estimates, and it is our opinion that there will 
be relatively few coins that require the total 1000 characters to describe. 

In addition to the actual data shown in the tables, there will be some 
additional overhead storage requirements for system and application programs, 
indices for key fields, and other minor things relative to the requirements 
for the two major files. 

Our study shows that it would be a definite advantage to have all informa- 
tion on all coins ’on line’ and available to the computer at all times, 
because of the general nature of research problems. • 
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3.2 ACCESSION HISTORY FILE 


FIELD NAME 

TYPE 

SIZE 

ACCESSION NUMBER 

II 

12 (plus decimal points 

GENERAL DESCRIPTION 

III 

80 

DONOR 

III 

80 

FROM WHOM ACQUIRED 

III 

40 

PURCHASE COST 

IV 

8 (nearest $) 

FUNDING 

I 

1 

VALUE 

IV 

8 

GENERAL TEXT *1 

III 

80 

NUMBER OF OBJECTS IN 

ACCESSION IV 

5 

NUMBER ENTERED 

rv 

5 


*I Includes how acquired, remarks, keywords; can point to hard copy files. 
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3.3 COIN CATALOG FILE 


FIELD NAME 

TYPE 

SIZE IN CHARS 

INSTITUTION (ANS, HSA, etc) 

I 

1 


ACCESSION NUMBER 

II 

12 


FUNCTIONAL TYPE (coin , medal , etc) 

I 

1 


DEPARTMENT 

I 

1 


SERIES (dynasty , nation, etc) 

II 

20 


SUB-SERIES (ruler, etc) 

II 

20 


DENOMINATION 

II 

20 


MINT 

II 

20 


DATING SYSTEM 

I 

1 


DATE(S) 2 

IV 

4 

each 

MATERIAL 

I 

1 


PREVIOUS COLLECTIONS 

III 

80 


PHOTO NEGATIVE NUMBER 

II 

10 


DISPOSITION (also hard copy file) 

IV 

6 


WEIGHT (g) 

IV 

6 


DIMENSIONS 2 

IV 

4 

each 

SHAPE 

I 

1 
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MANUFACTURE 

I 

1 

DIE AXIS 

I 

1 (12 pts of the clock) 

ANALYSIS (composition, condition) 

III 

80 

PUBLICATIONS 

III 

80 

OBVERSE TYPE 

III 

80 

REVERSE TYPE 

III 

80 

OBVERSE LEGEND 

III 

80 

REVERSE LEGEND 

III 

80 


3.4 INDICES OR KEY FIELDS 

All fields within each file should be defined as key fields because of their ex- 
pected heaAry use during inquiry searching. 
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4.0 INPUT REQUIREMENTS 


4.1 INTRODUCTION 

This section deals with the requirements for entry of data into either of the 
two major data files and presents sample screen formats. Data entry will be 
accomplished by a technique known as 'formatted screen input'. This technique is 
much more productive and easy to use than a query/response technique where each 
data field is prompted by a line display and requires operator response for each 
query line. In this technique, the CRT screen is 'painted' with a format of labels 
indicating the names of the fields to be input, and the operator inputs each 
field beside the appropriate label. All information can easily be seen by the 
operator at all times, and each field can be verified as to it's validity (e.g. 
alphabetic characters will not be accepted in a numeric field type). The operator 
can move the cursor around through the fields via keyboard special function keys 
and edit the data before 'releasing' it to the computer for validation. In the 
case of validation errors, appropriate error messages will appear on the CRT to 
indicate the field in error, and the operator will then be allowed to correct 
the field. Once a screen of data has been accepted as valid by the computer, it 
will be possible to clear only part of the data displayed before the next entry 
to facilitate entry of data for which many fields will have the same value, 
thereby increasing operator input efficiency. The screens shovm are only samples 
and do not necessarily depict the final screen formats to be used. 
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4.2 ACCESSION DATA INPUT 


ACCESSION NO 

FUNDIN G COST VALUE 

GENERAL DESCRIPTION 

GENERAL TEXT 


KEYWORDS 
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4.3 COIN DATA INPUT 


Coin Data input screens would be very similar, but probably broken up into 
two screens, one to collect type I, II, and IV data field types, and another 
to allow entry of free text and keywords. Samples of these screens are not shown. 

4.4 INITIAL ENTRY 

It is anticipated that initial entries will be made concurrently in the accession 
and coin files. A special problem exists at the ANS because approximately 225,000 
objects lack preassigned accession numbers (the link between the accession and 
coin files). CDS will develop the program to segregate this class of objects to 
facilitate matching of the accession and coin records. 

A flow chart of the entire initial entry procedure will be constructed as a 
guide for ANS personnel. 
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5.0 PROCESSING REQUIREMENTS 


5.1 INTRODUCTION 

This section addresses the general processing requirements of your application 
related to the major functional areas of data collection, searching, and report 
formatting. Our analysis indicates a general need for flexibility to change, and 
efficient processing of data base inquiries as major considerations. Ease of 
operation and maintenance are always objectives, especially significant in this 
case since there is a definite possibility of un-trained ANS visitors using the 
system. These requirements refer not only to the hardware performance needs for 
your application, but also to the software programs. 

* Purchased General Solutions 

This would be packaged software that has been developed by another 
vendor, and if carefully selected, can be more comprehensive in 
performance and less expensive than developed general software. We have 
evaluated several packages software inquiry and reporting programs 
that we believe offer a favorable cost/performance result. 


5.2 DATA COLLECTION 

Because of the initial entry task, we see a need for what is commonly called 
'formatted screen data entry'. This technique is described more completely in 
section 4, and provides an easy to use and efficient means of getting into the 
system the data you already have in one form or another. There is a requirement 
for flexibility in these screen data entry modules, in that you may be altering 
the data base contents as you become more familiar with the capabilities of the 
system. There is also a requirement to be able to add additional screen collection 
modules for new applications that may be added in the future. 
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5.3 DATA BASE SEARCHING 

The software that provides for Inquiry and reporting of the data base contents 
must be very efficient, flexible and easy to use. This is the most critical 
aspect of the entire application. It should provide access to any and all fields 
of information in both of the major data files, whether these fields are key 
fields or not. As pointed out in section 7, searches based on non-keyed fields 
will require a sequential search of the entire data base and will therefore 
take much more tim.e than searches of keyed fields. While these types of searches 
will take longer, they must be available; in other vjords, the difference should 
be measurable in hours at the most. For example, a search that involved several 
non-key fields might be a one time report, but should be producable in several 
hours of processing time. 

5.4 REPORT FORI-IATTING 

The requirement for flexibility extends to the facilities for formatting reports 
of inquiry results. Users of the system should be able to format a report con- 
taining whatever information is desired with ease in a short amount of time 
(see section 6 for more details on reporting requirements). 
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6 . 0 OUTPUT REQUIREMENTS 


6.1 INTRODUCTION 

This section identifies the requirements for output from the data base to 
CRT screens, hard-copy devices (printers), and machine-readable format (tape). 

6.2 STANDARD REPORTS 

Our analysis has identified at this time the following requirements for output 
which we will refer to as 'standard reports'. This means that they will be 
readily available by selection from a report menu. These standard reports include; 

* ACCESSION HISTORY REPORT 

This report will show any range of accession history records by 
accession number, and will include all fields related to the 
accession history file, but not detailed coin descriptions from 
the coin catalog file. 

* MASTER LIST 

This report will be the 'master listing' of all information in 
both data bases; accession history and coin catalog. 

Variations of these reports will cover most conceivable requirements by providing 
options on printed sort order. For example, one report may be by ascending 
accession number and another by department names with accession information 
ascending within each department. 

6.3 INQUIRY REPORTS TO CRT, PRINTER 

The most significant requirement for display of inquiry results to the terminal 
and printer is that a user be able to easily specify a report's content and 
format in columar fashion. Page headings, column contents and titles should 
all be controllable by the user. 
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6.4 VIDEOCOMP OUTPUT 


Output from the data base should be formatted for composition by computer- 
driven photo composition equipment. Data entry procedures will include 
assigning tags designating typography and diacritics. 
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7.0 INQUIRY REQUIREIIENTS 


The inquiry requirements refer to CRT oriented research into the data base of 
accession and coin information. This facility would be simple to use and easy 
to learn. It would also provide as completely as possible a flexible and general 
tool. Users must be able to describe to the computer system in English like 
sentences the parameters and selection criteria desired for a particular inquiry, 
as well as output report format specifications if desired. It must default to 
some standard output format when the user does not wish to specify it. It must 
provide an effective research tool for all users from simple to sophisticated. 

Specifically, the above mentioned requirements make the task of developing such 
software very complicated, time consuming and expensive. There are several 
packaged Inquiry systems available for the proposed mini computer, and they meet 
most all the requirements outlined. These packages are available for much less 
then we could develop similar software, and are field proven and necessarily 
completely flexible. This sort of packaged software could be utilized for 
additional applications to be added to your system in the future. It is our 
opinion that a suitable package be selected to fulfill the Inquiry requirements, 
and we are currently evaluating several other available packages. 
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8.0 APPLICATION DEVELOPMENT SCHEDULES 


8.1 INTRODUCTION 

The following schedules show in general the tasks to be performed for completion 
of the project on a mini based system. These schedules will vary some after 
the completion of Phase II, Detailed System Design, but are accurate enough 
for the cost comparisons shown in section A.O COST ANALYSIS. 

These schedules do not reflect actual elapsed time for completion of each 
task, but rather only total hours required to accomplish each task. A detailed 
time schedule will be developed during Phase II of the project, and enforced 
through our project progress reviews. Application software design and coding 
time requirements may vary with selection of specific equipment and packaged 
software. This aspect of the project is difficult to estimate at this time, 
and it should be realized that it could vary as much as fifty percent (50%). 


8.2 MINI COMPUTER BASED SYSTEM 


TASK LIST 


HOURS 

SELECT AND INTEGRATE HARDWARE (AXXESS) 


160 

APPLICATIONS SOFTWARE DESIGN AND CODING 

SYSTEM MAINTENANCE 


80 

DATA COLLECTION 


160 

REPORT GENERATION 


160 

INQUIRY 


160 

SYSTEM TESTING 


48 

ACCEPTANCE TESTING 


24 

ON SITE INSTALLATION (PRIME) 


32 

OPERATIONS FOLLOW UP 


16 

FINAL DOCUMENTATION AND PROJECT CLOSURE 


80 
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9.0 CONVERSION CONSIDERATIONS 


9 . 1 INTRODUCTION 

The conversion from your current manual system to a fully computerized system 
will proceed as follows once the final equipment configuration has been 
selected ; 


a. CDS to consider developing software at Axxess office to avoid 
transhipping ANS system (most damage occurs during shipping) . 

b. While our staff is developing the application software, CDS will 
guide ANS in preparing your site for installation of the computer 
system. This will involve physical preparation for security, 
environmental control, power supply conditioning (if necessary), 
and supplies acquisition for such items as printer paper and ribbons, 
etc. Prime field engineer will consult and provide ANS written 
approval of site preparation prior to installation. 

c. Once the system has been completed and accepted by ANS, it will be 
shipped to ANS, and CDS, under the direction of Prime, will install 

t 

it on your site with trained vendor personnel available to unpack and 
connect the hardware. The vendor personnel will perform hardware 
acceptance testing to ensure that it is all functioning properly. 

d. With the hardware Installed and checked out, CDS will then Install 
the applications software and begin ANS personnel training. CDS will 
remain on site until the 'system' is functional and initial data 
entry is under way. 
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e. CDS will remain available free of charge for the warranty period 
to correct any problems discovered with our applications software. 

f. CDS will warrant acceptance for service by Prime of entire ANS com- 
puter facility, including all peripherals, under initial manufacturers’ 
warranties and through Issuance of a standard Prime service contract. 

9.2 SETUP AT ANS, PHYSICAL REQUIREMENTS 

The proposed system will require approximately 170 square feet of floor space 
(ca. 8 X 21) in a room with at least 8 feet of ceiling clearance. The equipment 
will present about 1500 to 2000 pounds of load on the floor structure. The 
environment must be controlled generally within the limits of 50 to 90 degrees 
Farenhelt and 30 to 80 percent relative humidity. The power supply must consist 
of a combination of 15, 20, and 30 amp outlets at both 120 and 240 volts alter- 
nating current. Heating, ventilation, and air conditioning will have to handle 
a load of approximately 12,500 Btu/hour, 1 ton of cooling capacity. When 
specific hardware has been selected, CDS will interact with the vendor to outline 
specific physical requirements necessary for installation of the equipment. 

9.3 PERSONNEL TRAINING 

4 

While there will not be a need for ANS to provide a dedicated operations staff 
for the proposed system, there will be specific responsibilities associated with 
operation of the system that must be assigned to someone. ITiese responsibilities 
pertain to daily power up and down procedures, general weekly cleaning and main- 
tenance of the equipment, interfacing with CDS for solution of problems, and 
resolution of usage conflicts, to name a few. CDS will be on site for about two 
weeks during installation of the system at ANS, and will hold numerous classes 
to provide complete orientation training for all ANS personnel. This will include 
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management, operations, data entry, and research personnel training. 


9.4 INITIAL ENTRY OF EXISTING DATA 

The initial entry of existing accessions and coin descriptions will be an on- 
going task for at least 3 years. Predictions for the time required are rough 
estimates now, but based on an estimate of thirty (30) seconds per coin des- 
cription, it will take about three years to enter descriptions for all 1,000,000 
coins assuming two persons working 61/2 hours a day. The estimate of thirty 
seconds per coin is a guessed average. 
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10.0 ADDITION OF OTHER APPLICATIONS 


10,1 LIBRARY DATA BASE, ACCOUNTING, PAYROLL, ETC. 

The Prime system is a true general purpose computer accommodating any number 
and variety of applications, limited only by performance constraints of the 
system. Creation of a data base system for cataloguing the library collection 
is anticipated during years 4—5. Campbell estimates that the catalogue revision 
project will be completed in 1985 at which time conversion of the card file 
could begin. 

Conversion of the accounting records is estimated on the basis of limited 
modification of prepackaged applications softw’are. 
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11.0 COST ANALYSIS 


11.1 INTRODUCTION 

Due to the potential for variance in software development requirements, CDS 
would propose a Time and Materials rate of $30.00 per hour for the Project 
Manager, and $25.00 for the analyst /programmer . All software cost estimates 
are based on these figures. 

11.2 MAJOR COST COMPARISON TABLE 

In addition to the breakdowns below, the Prime mini computer systems will 
require installation of heating, ventilation and air conditioning equipment. This 
equipment will cost $7,000 to $10,000 depending on exact requirements of final 
hardware selection. There may be a need for device that ensures a clean, consis- 
tent power supply if the standard service in your area is subject to fluctuations 
or frequent failures. The cost of such a device will be in the range of $1,500 
to $2,500. 


EQUIPMENT OR SOFTWARE 


PRIME (See budget) 


CPU AND MEMORY $37,100 

DISK 28,500 

TAPE 12,000 

PRINTER 4,000 

CRT 2,000 

PURCHASED SOFTWARE * *1 5-12,000 

APPLICATION SOFTWARE *2 14,000 

TEST, INSTALL AND DOCUMENT 5,240 


*1 This will vary depending on final selection of available packaged 

software. We are currently evaluating a package available for the PRIME 
system, and have others to evaluate. 

*2 The cost of application software develop will vary depending on packaged 
software selected as well as the final hardware selected. It could 
vary as much as +50%. 
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11.3 OPERATING COSTS 


There are a number of operations costs summarized below, and these are estimates 
as well. Power refers to electricity for the computer as well as the environ- 
mental control equipment. Supplies refer to such things as paper, printer ribbons, 
tapes, and so on. Maintenance refers to contracted support for the computer 
hardware. 


POWER 

SUPPLIES 

MAINTENANCE 


OPERATIONS COSTS SUMMARY 
(MONTHLY ) 


1980$ (See budget) 


$ 210 
180 
1000 


TOTALS 


$1390 


11.4 TOTAL COSTS SUMMARIZED 

The table summarizes the capital investment costs for the mini computer 
system. 


PRIME 

HARDWARE $ 83,600 

SOFTWARE 27,240 * *1 

TOTALS $ 110,840 (See budget) 

*1 based on estimate of $8,000 for packaged software in Prime system 


37 


12.0 EXECUTIVE SUMMARY 


The mini computer system proposed by CDS will feature the ability to immediately 
enter into the accession history file new accessions as they are acquired, 
providing timely and accurate accountability of ANS’s activities. Entry of 
detailed information pertaining to individual objects can be accomplished by 
staff members or users as work in specific areas of the collection progresses. 
Administrators will be able to quickly respond to Inquiries concerning the 
ANS’s history of accessions from the first to the most recent. 

Staff members and users of the ANS collection will benefit from research 
facilities making possible inquiries that are now Impractical because of time 
considerations. These facilities will provide results to research questions in 
a few hours that now require weeks or months. All of the ANS personne.'i and users 
will benefit from a single computer facility centralizing any and all information 
about accessions and objects. 

The advantages of a mini computer over a micro computer all derive from the 
flexibility of the final mini computer based system. As new accountability and 
research needs become apparent, the mini computer system will allow the addition 
of new data fields, keys, indices, reports, and inquire methods to meet these 
needs. If new applications become desirable, or data storage requirements for 
the proposed system grow, the mini computer system will allow addition of larger 
disks, faster printers, and more CRT terminals. The mini computer system will 
change and grow with ANS. Staff members will be able to develop their own 
programs in BASIC for specific use of the coin data base, an advantage which 
we believe will become more significant as familiarity with the system increases. 
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On the basis of our analysis and evaluation, CDS recommends that a mini 
computer be selected for the development of your application. If this is in 
accordance with your budget and plans for the future, we would be eager to 
begin Phase II of the project, detailed design of application software and 
selection of a specific mini computer. 


APPENDIX 


A 


GLOSSARY OF TERMS 


Application sof tv?are 

These terms refer to the programs that relate specifically to your 
application of the computer to ANS activities. 


Bit 

Byte 

V/ord 


These terms all refer to units of measurement for the computer's 
memory and disk storage capacities. One bit refers to one binary digit 
of information (0 or 1), eight bits make up one byte, and two bytes 
make up one word. 

- . . 8 Bits = 1 Byte 

16 Bits = 2 Bytes = 1 Word 


Byte 

A byte is the term that refers to the computer storage required to 
hold one character of information, where a character is any letter 
of the alphabet, number, or special character (*&//^, etc.). It is 
used as a unit of measurement for the computer's memory and 
disk capacities. Abbreviations of terms often associated with 'byte' 
are K for one thousand bytes (1KB = 1000 bytes), and MB for one 
million bytes (1MB = 1,000,000 bytes). 


Cursor 

The cursor is the blinking underscore character that appears on the 
crt screen to indicate position. Used in formatted screen data input, 
it indicates v/hich field is being entered and moves through the format 
to allow entry of data in a specific order. 

Data Base 


A term referring to the sum total of all information stored in 
whatever manner in the computer system. In your application, it is 
used to refer to all information contained in both the accession 
history file and coin catalogue file. 
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File 


Record 


/ 

Field 


These terms refer to a heirarchy of information levels; a file is 
a group of related records, each record containing the same fields. 
The following depicts the relationship of these terms. 



FILE 

Coin //I Description,.., 

Coin i\2 Description,.., 


Mint 

Mint 


RECORD 

Coin 3'/12345 Description,.., 


FIELD 

Mint 


Coin //n 


Description , . . , 


Mint 


Ind ices or Key Fields 

The term further qualifies a data field as a special type. It differs 
from other data fields in that it is stored and accessed differently. 
The primary reason for making a field a key is because it is expeced 
to be used heavily in inquirys. A key field can be processed or 
searched much faster that a non-key field. There is an additional 
storage requirement involved with a key field, and that is why a data 
base is not all key fields. 

Key V/ords 

Refers to speeific words within free text that are meaningfull. These 
special words will be treated similar to key fields in that they will 
be available for searching within the inquiry sub-system. 
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Menu 




Refers 
letter . 
all of 
for reference, 
abbreviations of 
list appearing in 


a table of 


to 

A menu driven system is 
the given application's 
The operator 
program names, 
the menu. 


selections specified by entering a number or 
easier to learn and operate because 
options alvjays appear on the screen 
does not have to remember any 
they are simply selected from the 


Systems sof tv;are 


The programs 
for solution 
actually 


that are required to use the 
of your application. Your 
use the 


computers hardware devices 
application softv/are will 
systems softv/are. 
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